Smart Cards have been around for quite some time and are used frequently as debit and credit cards, among other things. Smart Cards, as the name implies, are processor controlled and also include a small amount of memory to retain identification and transactional related data. The ability to create and run Java based programs on Smart Cards has recently been developed and is gaining popularity. Java based programs can also be implemented in other intelligent devices, such as the mass storage memory cards typically used in digital cameras and music players. These other cards are recognized as mass storage devices because they must store and access very large libraries of data, such as photos and music, orders or magnitude larger than the transactional and identification data stored in a Smart Card. Examples of these mass storage cards are the compact flash (“CF”) card, secure digital (“SD”) card, mini SD card, micro SD card, multi-media (“MMC”) card, and memory stick. There are many more different formats of mass storage cards in addition to the recited examples. Portable flash memory based universal serial bus (“USB”) drives are another type of portable mass storage device.
Java Card™ technology enables programs written in the Java programming language to be run on smart cards and other small, resource-constrained devices. Developers can build and test programs using standard software development tools and environments, then convert them into a form that can be installed onto a Java Card™ technology-enabled device. Application software for the Java Card™ platform is called an applet, or more specifically, a Java Card™ applet or card applet (to distinguish it from browser applets).
While Java Card™ technology enables programs written in the Java programming language to run on small Memory cards, such small devices are far too under-powered to support the full functionality of the Java platform. Therefore, the Java Card™ platform supports only a carefully chosen, customized subset of the features of the Java platform. This subset provides features that are well-suited for writing programs for small devices and preserves the object-oriented capabilities of the Java programming language.
Java Card™ is one type of virtual machine. Other virtual machines are also available, and a virtual machine is an abstraction of a physical processor and has virtual counterparts of a conventional processor. In the case of the Java language, a Java virtual machine is software that acts as an interface between compiled Java binary code and the underlying hardware platform microprocessor.
One application that would be particularly useful when implemented in such a small device involves payment for protected content such as music or movies etc. . . .
In order to run applications written in Java, the Java Card™ virtual machine must be loaded into the card and activated. Each instance of the machine requires payment of a license fee to Sun or to the supplier of such components. Because the main purpose of a Smart Card is transactional, the cost of the license fee is acceptable to the issuer of the card as a cost of doing business. However, the user of a memory card of the mass storage type may or may not have a use for the additional applications that the virtual machine makes possible, because the typical user possesses and uses the card primarily for the purpose of data storage. Therefore, the manufacturer cannot pass-on or absorb the cost of the license fee as a matter of course. Furthermore, each of the applets or other programs that run on the virtual machine(s) may also require a license fee that cannot be passed on (to a user that may have no use for it), or absorbed as a matter of course.
The role of the Java Card™ virtual machine is best understood in the context of the process for production and deployment of software for the Java Card™, platform. There are several components that make up a Java Card™ system, including the Java Card™ virtual machine, the Converter for the Java Card™ platform (“Java Card™ Converter”), a terminal installation tool, and an installation program that runs on the device. Development of a Java Card™ applet begins as with any other Java program: a developer writes one or more Java classes, and compiles the source code with a Java compiler, producing one or more class files. The applet is run, tested and debugged on a workstation using simulation tools to emulate the device environment. Then, when an applet is ready to be downloaded to a device, the class files comprising the applet are converted to a CAP (converted applet) file using a Java Card™ Converter. The Java Card™ Converter takes as input all of the class files which make up a Java package. The Java Card™ Converter also takes as input one or more export files. An export file contains name and link information for the contents of other packages that are imported by the classes being converted. When an applet or library package is converted, the converter can also produce an export file for that package.
Normally, after conversion, the CAP file is copied to a card terminal, such as a desktop computer with a card reader peripheral. Then an installation tool on the terminal loads the CAP file and transmits it to the Java Card™ technology-enabled device. An installation program on the device receives the contents of the CAP file and prepares the applet to be run by the Java Card™ virtual machine. The virtual machine itself need not load or manipulate CAP files; it need only execute the applet code found in the CAP file that was loaded onto the device by the installation program.
These and other aspects of the Java Card™ Platform are described in the following specifications from Sun Microsystems, which are hereby incorporated by reference in their entirety: Application Programming Interface, Java Card™ Platform, Version 2.2.1; Runtime Environment Specification, Java Card™ Platform, Version 2.2.1; and Virtual Machine Specification, Java Card™ Platform, Version 2.2.1.
As mentioned above in order to run applications written in Java, the Java Card™ virtual machine must be loaded into the card and activated.
In one prior approach described in U.S. Pat. No. 6,772,955 to Yoshimoto et al., a virtual machine is provided as part of the memory card controller chip in order for the card to be used in point based transactions. The source code for employing the card as a point card is written in Java and is loaded into the card. A point balance is updated for each item purchased with the card.
Each instance of the Java Virtual Machine requires payment of a license fee to Sun or other suppliers. Similarly any other proprietary virtual machine may require payment to the licensor of such a machine. In a Smart Card, each card is provided with an active and paid copy of the Java Card™ virtual machine. This adds to the cost of each Smart Card, as it likely does to the system described in the Yoshimoto patent. Because the Smart Card's principle function is transactional in the majority of applications, this cost can be absorbed and/or passed on to the manufacturer, middleman, or consumer. However, it is undesirable to absorb or pass on the cost of the license in a consumer mass storage device, where the functionality of the virtual machine may never be utilized.
Global Platform is an industry consortium for the advancement and standardization of Smart Cards. Global Platform acts as a smart card industry standards body, creating and maintaining an open technology framework for the global deployment of smart card programs by many service providers across many industries. The Global Platform application programming interface (“API”) and other aspects of the Global Platform are described in The Global Platform Card Specification. V. 2.1.1 and the Formal Specification of Global Platform Card Security Requirements, dated December 2004, which are available at www.globalplatform.com and hereby incorporated by reference in their entirety. Global Platform provides for the downloading of applets to a smart card or other device that already has a virtual machine. However, while this provides applets and the associated functionality as needed, it does so for cards that already have the virtual machine required to run the applets.